High-Level Architecture

The following diagram provides a high-level overview of the architecture for high availability for cloud licensing.

The elements in this diagram are described below.

Client Application

The client (protected) application integrates with the Sentinel LDK Licensing API. You can configure the Licensing API (or License Manager) INI file to set serveraddr with the DNS address.

The Licensing API (or License Manager) always attempts to contact all of the available License Managers in parallel, and it uses the one that responds.

The Licensing API for cloud licensing uses HTTP with a proprietary cryptographic algorithm. This protocol is similar to TLS-PSK.

Regardless of the protocol used, security is guaranteed by the identity protocol, which provides authentication for both the server and client sides and ensures confidentiality through encryption.

The extra HTTPS layer is mainly intended to satisfy potential regulatory requirements. However, HTTPS affects performance because setting up the secure channel requires additional communication round trips between the client and the server.

Thales recommends that from the LM side, the customer use a reverse proxy or a load balancer to enable HTTPS. Internally, these use the HTTP protocol (this is a common practice in the industry).

On the client side, if the LM service is hosted by the software vendor, the vendor must call the hasp_config function (in the native Licensing API) to set the public certificate, or the identity string should include the 443 port. For example: ZP7MMCG:oBWAAQCBEG8khbnRdNWldr9xQHZEphc@LM_HOST:443.

For CL keys hosted by Thales, HTTPS is always enforced automatically. No action is required.

DNS Service

When two license manager services bring redundancy capability, the load balancer (NGINX) itself can still leave a single point of failure. High availability for the load balancer layer can be improved using one of the following options:

>Using DNS with single floating IP address

Floating IP is a static public IPv4 address that can be attached to both reverse proxy instances. It directs traffic to one instance at the time and can be switched between multiple instances immediately. For this option, the DNS record only needs to contain one static IP address.

>Using DNS with multiple IP addresses

You can create a DNS “A” record to store multiple IP addresses of reverse proxy instances.

Reverse Proxy

The reverse proxy should be configured as active-active mode. As a result, license requests will be redirected to one of License Managers based on the load balancing policy. For example, round-robin or least-connected load balancing can be used. If one of the License Managers is down, a "retry login" mechanism implementation is not required in the client application code for active-active deployment.

The reverse proxy can perform an active health check via the following License Manager health check end point: /sentinel/ldk/v1/healthz

When a load balancer is used, it should be configured to use the same License Manager service instance for a given client or session. For more information, see Requirements for the License Server Machines.

Load Balancer Policy

Sentinel Licensing API is not a stateless API. When using this API, you must configure a sticky session policy in the load balancer or reverse proxy to ensure that a client request is redirected to a specific network server for the duration of a session.

In general, cloud licensing supports three sticky session policies:

>IP hash – The IP address of the client is used to determine which server receives the request.

>Consistent hash – The client generates a unique ID. Sentinel LicensingAPI has a special HTTP header (X-LDK-Instance).

>Session cookies – The load balancer assigns a unique cookie ID back to client, and the next request from the client carries this cookie back to the load balancer.

License Manager Service (LMS)

The high-availability solution is only valid for an LMS based on trusted license storage. To enable this type of storage, you must first set environment variables or use the License Manager INI file to enable the License Managers to connect to the MySQL database. Next, you use Sentinel EMS to generate an authorization file, and apply the file to one of the License Manager instance. This enables the License Managers to use the MySQL database as a trusted license storage.

The Implementation for High Availability section demonstrates how to set up active-active license servers using Docker Compose and NGINX to handle License Manager failover.

MySQL Cluster

Machine on which a MySQL database or database cluster for license storage resides. The vendor has complete control over this database and is responsible for the security of the database. This machine serves as the trusted license storage unit.

Note that with trusted license storage, the database is readable and accessible by the vendor, but the internal blobs in the database are still encrypted with the Vlib secrets.

Summary of Differences Between Active-Active and Active-Passive Configuration

The table that follows summarizes considerations when you are changing from the active-passive configuration to the active-active configuration.

  Active-Passive Active-Active
Client Application

Retry must be implemented.

Retry is not required.

DNS

Use a DNS with a single floating IP address.

Or

Configure your DNS record as failover type (active-passive) to return only one healthy IP address at a time to avoid potential license abuse.

Configure the DNS record as active-active type with two IP addresses of reverse proxy.

Reverse Proxy

Reverse proxy should be configured for active-passive mode.

Reverse proxy should be configured for active-active mode.

License Manager Service

Run-time Environment on each cloud license server must be version 8.31 or later.

Run-time Environment on each cloud license server must be version 8.41 or later.

MySQL Cluster

There is no difference between active-active and active-passive configuration.